2023年6月5日，唯品会控股有限责任公司(以下简称“唯品会”)又上热搜了，但原因竟是一条宕机故障处理公告。
《关于329机房宕机故障处理公告》【唯品会通-[2023]年-[019]号】显示，2023年3月29日(00:14-12:01))，南沙IDC冷冻系统故障导致机房设备温度快速升高宕机，造成线上商城停止服务。此次南沙机房重大故障影响时间持续12个小时，导致公司业绩损失超亿元，影响客户达800多万，公司将此次故障判定为P0级故障。同时，唯品会认为此次事故暴露出容灾应急预案和风险防范措施不到位，并决定对此次事件严肃处理。对应部门的直接管理者承担此次事故责任，基础平台部负责人xxx予以免职做相应处理。最后，唯品会还认为工作不到位将导致功亏一篑，要求每一位员工都应当以329事件为戒。反思自己的日常工作，检视交付上的漏洞，梳理设计上的短板。勇于面对问题、主动反思和警醒，希望所有人以此为戒，痛定思痛，警钟长鸣!宕机是计算机术语，就是大家通常说的死机。因为机房宕机损失超亿元，不得不说事故重大。因为机房宕机而开除基础平台部负责人，有些网友认为处罚过重，但考虑到唯品会的过亿损失以及近12个小时的停机，这个处罚并不算过重，而且类似事件也有免职处罚。不过329机房宕机故障也暴露出了唯品会在容灾设计和应急预案方面存在的不足，相关部门的风险防范意识不到位。因拼写错误，17个数据库被删除，微软 Azure DevOps 罢工十小时
The register 网站披露，巴西南部地区部署的 Microsoft Azure DevOps 服务”罢工“了约十个小时。随后，微软首席软件工程经理 Eric Mattingly 为本次中断事件公开道歉，并透露中断原因是一个简单拼写错误致使 17 个生产数据库被删除。
Mattingly 表示 Azure DevOps 工程师会定期对生产数据库进行快照（Snapshot）处理，以便及时调查报告上来的问题或测试性能是否改进，这些举动都依赖一个每天运行的后台系统，该系统会在特定时间删除旧的快照。在 Azure DevOps 工程师近期进行的一次代码升级中，用支持的 Azure.ResourceManager.*NuGet 包取代了弃用的 Microsoft.Azure.Management.*包，此举引起一个大型的拉取请求，其中更换了旧包和新包中的 API 调用。然而拉取请求中却出现了拼写错误，误将删除快照数据库的调用改成了删除托管数据库的 Azure SQL Server 的调用，导致后台快照删除作业删除了整个服务器。事故原因
Mattingly 指出 Azure DevOps 有专门的测试来捕捉此类问题，但是错误的代码只在某些特定条件下才得以运行，因此在现有的测试中没有很好的覆盖到。（据推测，这些条件需要存在于一个足够“老”的数据库快照，以便被删除脚本所捕获。）Mattingly 进一步指出由于没有任何快照数据库，Sprint 222 的内部部署（第0环）没有发生任何意外，几天后，软件变更被部署到客户环境（第1环）被用于南巴西规模单位（一个特定角色的服务器集群）。该环境中有一个快照数据库，其年龄“老”到足以触发该错误，最终导致后台工作删除了该规模单位的“整个 Azure SQL 服务器和所有 17 个生产数据库”。
经过十多个小时的努力，微软方面已经全部恢复了数据库，为防止此类问题再次发生，微软已经采取各种修复和重新配置措施。花费如此长时间的原因如下：第一：由于客户自己无法恢复 Azure SQL Server， 必须由 Azure 工程师来处理这一问题，这一过程大约需要一个小时；第二：数据库具有不同的备份配置，一些数据库被配置为区域冗余备份，另一些数据库被设置为最近的地理区域冗余备份，协调这种不匹配的冗余备份，需要花费几个小时；最后一个原因：在数据库开始恢复在线后，由于自身网络服务器存在一系列复杂问题，使用这些数据库的客户也无法立刻访问整个规模单元。据悉，这些问题由服务器预热任务引起，该任务通过测试调用在可用数据库列表中反复进行，恢复过程中的数据库出现了一个错误，就会触发预热测试 执行指数回退重试，导致预热平均需要 90 分钟，在正常情况下此操作只需要几秒钟。更为复杂的是，整个恢复过程是交错进行的，一旦有一两台服务器开始接受客户流量，就会出现过载，然后停机，因此，恢复服务需要阻断所有到巴西南部规模单位的流量，直到一切都充分准备好后，才重新加入负载平衡器并处理流量。精彩推荐
6月期|华盟信安2023网络安全就业班开班计划
重磅|2023华盟HW工程师招募